Executive Summary
The SmallWorld team's morning standup focused heavily on infrastructure cost optimization and autoscaling strategy for Sidekiq workers, driven by a ~$4,500 cost incident and pressure from Postman to process data faster. The team celebrated a dramatically reduced AWS bill ($800 for May 1) and now has full Sidekiq job instrumentation in DataDog for the first time. A significant architectural discussion around embedding SmallWorld's relationship map into Salesforce via iframe took shape, with the team aligning on an iterative approach — ship offers-for-help and relationship leads first, defer deal team and extended network until the concierge is ready. Authentication strategy for the iframe remains an open question requiring exploration.
Mind Map
mindmap
root((May 6 Overview))
Infrastructure
Autoscaling
Workers scale 2 to 60
Queue separation needed
Default vs user notifications
Costs
$4500 incident
AWS bill down to $800
Keep costs minimal
Sidekiq Monitoring
DataDog instrumentation live
Per-job cost visibility
SmallWorldPsychic traces
Postman Sync
Running slowly, minutes per run
May have missed days of data
Manual re-run last night
Root cause unclear
Salesforce Integration
Relationship Map Iframe
Offers for help
Relationship leads
Deal team
Extended network
Authentication
SFDC ID is identification not auth
Explore trusting SF session
Fallback custom login page
Iterative Rollout
Deploy to Rails first
Build iframe in parallel
Team Updates
Cam
PRs pushed evening prior
Rally search filters
KPM fanning-out deployed
Judoscale PR tested
Todd
Salesforce 290 branch
User provisioning ticket
David
Salesforce planning session
Calendar management note
Action Items
Autoscaling & Queue Architecture
Postman Sync & Sidekiq
Salesforce Relationship Map
General
# Transcript: 2026-05-06 > 2 time blocks from 7:57 AM to 9:13 AM --- ### Team standup autoscaling discussion **7:57 AM - 8:36 AM PDT** | *meeting* **Microphone:** Bye. Ugh. Thank you. I'm sorry. I'm going to go to the next one. Hi, girl. What's up, Kiba? Croissant. Here we go. I just suck, guys. Wanna get up here, Bruce? There you go, buddy. Good morning, guys. Cam, thanks for pushing out those PRs last evening. Let's talk about autoscaling. I know Frank can't switch with David last night, but we can save money and have servers that automatically scale based on the queues themselves. That's what this is doing. It will scale back down to one once I turn it on, and I'll do that shortly. For workers, there's no set schedule, and that's okay. It scales from 2 to 6 to 60, and then back to 2. That being said, given what I'm seeing here and they run so fast, I'm starting to think we want to set up a queue that only gets the default queue and user notifications, so we know that Chrome syncing and user notifications don't get held up. That makes sense. I mean, is it not a mistake to have Chrome extension in the default queue? I don't think it's a mistake. It just is what it is. When you start, everything goes in the default queue. You add things as needed, or we can extend it. I guess "mistake" wasn't the right word. I was trying to say, given the user notifications, yeah, not anymore. It's just that things will take from the default queue more now. The other thing we could do is ramp up the default queue to around 30, make it like 10, and if this is three, that means three out of the total. There's also capsules. I'm not sure if that's useful for multiple builds or deployments. You'd have a separate capsule with these four queues for the Rails app and a separate capsule with these seven queues and two workers for the Go app, or things like that. I see. But I looked into it when you last recommended it. Yeah, so you could just configure default that way. It's crazy. So that's the question. I think we'll probably go that path too, just so everyone's aware. Postman had an issue yesterday. It's not really clear what exactly happened. The costs came to about $4,500. We need to keep costs as small as humanly possible. I communicated back to him that we need more servers or it's gonna get throttled, hence the autoscaling. The other piece is that Postman's sync has been running, and I ran it again manually last night. And then honestly, if it's what I'm afraid of, we might have missed information for a couple of days. As far as I can tell, it takes on the order of minutes to run, and that's a problem. We hadn't previously been monitoring the Sidekiq jobs in a fully instrumented way, so we could see how long they ran. We should now be able to see the actual underlying cost of each job. I'll share my screen because they're just starting to show up. We can essentially break it down by job and understand things correctly. Yeah, so like millisecond-level operations. That's awesome. Let me search for sales. I hope there's not something going wrong inside the pipeline that's preventing target companies from being created. All right, so there might be multiple things at play. I haven't found anything definitive yet. I'm just looking now because I definitely enqueued a bunch of stuff yesterday. It's the batches. We're gonna make sure the Sidekiq jobs are being properly logged so we can get a better understanding. That was an RLO processing job. This is gonna be fun to look at. Where's the trace? Oh, there it is. I was gonna say, there has to be a gap. Look at that. It's a lot easier to understand some of these things by breaking it down. Today I'm chatting with David after our meeting about Salesforce. We're still working on Salesforce stuff. Again, apologies for having to move that meeting from yesterday, David. After two years, I've learned we would benefit a lot from David using both his work calendar at David@smallworld.ai and his personal calendar. We're going to talk after this about Salesforce and the iframe for the relationship maps. We can work out some plans there. And then I think I'll be focused on Salesforce for the day. A pretty productive day. I started the day wrapping up the rally. I suggested search filters, did another round of testing, and addressed the recent feedback. A Honey Badger exception came up along with some references to SuperConnect code, which was nice. Tested the Judoscale PR to make sure everything deployed correctly. Implemented the KPM fanning-out strategy. All of that went swimmingly. Nothing exceptional happened during testing. Got it all merged and deployed. Then I spent the other chunk of the day discussing with Michael and putting notes together. But that was me. How about you, Todd? I started Salesforce stuff on the 290 branch and I'm trying to get that set up. Since Salesforce came in, there was a Rails-side ticket about provisioning a new user. I was assuming we'd skip that for now given our scope of work. Not sure what comes next. Cool, okay. So then the main focus today is really Postman and we'll go from there. So you want to talk about Salesforce and the relationship map for a bit? Not yet, give me a moment. Okay, so here's the relationship map. Obviously, stuff is still being worked on, but the ideas are getting pretty concrete at this point. There are four pieces of the relationship map that he offers for help: relationship lead, relationship deal team, and then extended network. We want most of this automated, and there are only a few things you'd have to do when looking at this page that we're trying to draw the most engagement with, which is acting upon it. Part of the idea here is that you don't have to search for relationship leads. As more things happen—connectors decline, connectors accept, offers appear—you can act upon them. So really the only things you can act upon on this page are the relationship leads and the offers for help. We want to keep the engagement focused. The offers for help are not in Salesforce, so bringing them into a page within Salesforce is a win. People don't actually want more platforms. Connect or SureSel don't, and that's one of the mountains we're up against. What we could do here is iframe the content of this tab and have a specific page that is just the relationship map. If I look at that, you can see this dark blue part here is pretty touristy—it's not the Chrome. But the Chrome, our header, even the name of the company is useless in Salesforce because they already have that. That's not really the point. Make it available in Salesforce. The big piece also is that we can work iteratively. Cam and I talked yesterday about building out the relationship map. One of the things we said was that the concierge is doing stuff, so it's going to take time, but in theory we could just deploy this page to the Rails side and have it load. What are your thoughts? Yeah. The real question is about all the stuff around the iframe, right? I just think we don't necessarily want to build this right now, but eventually if we see good uptake, then yes, we would want to build it. The iframe can be built and the embedded content of the frame can be built right along with the relationship page itself. I have to assume putting an iframe component into a new LWC component that can be dropped on a page is probably more lightweight than building out something completely native. The real question just becomes authentication. I don't think they had customized logins. When you log in, the equivalent of all of this stuff up here was still on their page. The other piece is if they are not logged in, they see a custom login page. Or we do what we did for the connector dashboard. We tested it where with the shared link thing, it comes to a custom modal. We could fake it so it looked like you're on the relationship page. It's a custom modal that I built that sits on top of an image of the background so you can run through the login process without having to leave the page. We're about to get hit by a bad storm. This is going to be easy because it just sits outside of Slack or outside of Salesforce, but it's going to have to be within the Salesforce iframe. It needs to work in the iframe and really be okay in a small window if need be. Any thoughts, questions, concerns? Seems fairly straightforward. I mean, maybe I'm totally naive for thinking that we could expose the SFDC ID, but that's identification, not authentication. If we call correctly, we were talking about how we even need a bearer key if we know it's coming from Salesforce. I wasn't exactly sure about that at one point. Kind of honestly, we should put less on us and more on the user. Salesforce is already kind of a semi-gateway for accounts. And then interestingly enough, since I was just working on that no-user ticket yesterday, they'll send the user ID because you're logged in. So we know somebody's logged in there. If they don't have an active session or user on our side, we could do a GET from somewhere to requester. Maybe you only need an account to be present. That's where it becomes personal and we would need an actual requester user role, but that's—it smells dangerous. It's fine if we've done our diligence and proven that it's not, though, right? What I would suggest is we could take it forward with a separate login page that fits the iframe for people who are not licensed. But if you could build it for the people who are licensed and we can trust the authentication or authorization coming from Salesforce, that's how it is. We have that origin stuff that I was actually proposing getting rid of because that was the thing. But now since it's going back more to—well, essentially ignore all origin problems. And really it becomes a win. I think putting the due diligence in is worth it, but I would just take some time to really improve the user experience. Yeah, because as we've seen, there's been a lot more requests from people who don't have SmallWorld accounts and logins actually using it. The package was installed with a pilot program of like eight people with auto-provisioned requester accounts, but I guess maybe at this point we probably don't necessarily care so much. Maybe the more people that see the product, the better. There's no need for some logic about not showing it anymore. I don't know why we would block anything that's just like fetching data from Salesforce. Yeah, I think it's a question of, well, you don't want other team members necessarily looking at data they shouldn't, but that's not our problem. That's the Salesforce internal admin. They can look at other accounts, right? I don't know if we're giving them a way to configure that though. We can install stuff and turn this on for people to see these accounts because they're the owners or they're in that region or something like that. Mm-hmm. Oh, okay. I see what you mean. You're talking about adding a whole page to begin with. I don't know if it's done in practice, but I can see it. I think that's a better model. Feels like a win. Yeah. Ha ha ha. So I'll also file a ticket for you just based on this conversation for doing some exploration. And then next week as we get a little closer, we'll figure out what's going to be on the page. Holy shit, wait for it—everything. April 1, uh-huh. Our May 1 AWS bill was $800. Let's go! Okay. I'll listen to our notes and like put together some notes and thoughts we had to see what you get. It's a good thing. Let us know if that's a feasible approach. Cool. How freaking great. Okay, well, then I think we can leave it there and give you guys some time back. I'm just thinking one last thing about the boxes and stuff. Okay, cool. Yeah, and actually it's funny. Cam and I were just chilling yesterday, kind of gearing up for the Rails 7 update. So anyhow, real quick—I'd have to drive my mom to the airport at 11:15, so I'll be... All right, no worries. Thanks for letting us know, team. Right? **System Audio:** Hey, good morning. Um, to start, where I've paused the GitHub action for auto scaling—I just had a frank conversation with David last night. At like five seconds timeout, and then just to be safe, it is now doing up to eight. Right now it's only looking at these three queues because I don't see it will scale back down to one once I turn on auto scaling. The web one I just did this morning and haven't actually turned on yet, but it'll do essentially what we were doing, which is it'll scale two dynos themselves. That's what this is doing. It is set up—just so you guys are aware right now. We actually have to spend some money, and this is one area where we can spend some money and it will automatically scale based on the queues. Hey guys, good. We'll see. So it'll—we're just getting fast. Separate type of worker process, like in default queue. Chrome syncing immediately and user notifications doesn't ever get held up in the mask. And actually, that's probably not true. It would probably, I would say maybe it would do default and user notifications just so we know the setup to just see how things go. That being said, given what I'm seeing here still, I am thinking I want to do the math on it. But given that the use—does that make sense? And we just never moved. So it is going to take from default more. The other thing we could do is we could ramp up the default queue prior. What happens is, like, right now, the reason I have enrichment indexing paused—we know that indexing, when we're doing like these morning batches, takes a long time. I don't think it's a mistake. I think it's just it is what it is. Like, you know, when you start, everything goes in default. You add things, we can extend. I don't think they're really useful if you're trying to run sidekick in like a sidekick for multiple either environments or multiple bits. You can just see now at default—we, you know, need more servers, it's going to get throttled. Target companies that aren't clearly updated, but the thing has been running. And I ran it again manually last night just on the target companies. So hence truly scale. The other piece is that we have Postman updating as quickly as he would like. And as I communicated back to him, that fast is weak. We need to keep costs as small as humanly possible. That being said, yesterday he was upset that Postman was—and then Postman shook the bed a little bit yesterday. It's not really clear what exactly occurred at this point. It's not clear if the queue is the issue. So it's easy how fast default flies sometimes. So that's the question. I think we'll probably go that path too, just so everybody's aware. Having hundreds of thousands of files. Yeah, I'll show you my screen because they just started showing up called SmallWorldPsychic. The enriched person job is not—and that's a good question. But what we want to eventually look into is like, these are all selections and stuff, but what is that? For writing such a crazy fast fucking job is like millisecond operations. And that's fucking awesome. Stand things correctly. Yeah. So like we can see that finally—okay, like the Chrome extension job, which thank you—to see within DataDog. Or we should be now able to see like the actual underlying cost of each job. We hadn't previously been monitoring the sidekick jobs like in a fully instrumented way. So we could see how long they ran, but we weren't able to see each partition file to get parsed. As far as I can tell, it takes on the order of like minutes to run. And so we have to stop the stuff we're doing for relation management for a couple of days, just to rebuild the jobs for Salesforce to make them work faster. Because right now it doesn't work the way you expect it and stuff like that. I think we're going to have to come with like a short term solution—like, we just mainly process. I've done that before, but it might be that I'm going to go look into that this later this morning. Um, and then honestly, if it's what I'm afraid it is, which is that like the process is slow—Lima data cost course. Anyone help me? It's probably the past 24 hours. Let's do that. Okay. So I'm just looking because I ran. I queued a bunch of stuff yesterday. Um, have to step down. data.psychic being properly dated on, which is delightful. Oh, wait, look at that. RLO processing job. This is going to be fun to look at. Where's the trace? It's the batches. Interesting. Okay. So I'm going to go ahead and see the next slide. There a lot easier to start. Yeah, that's not gonna change any time soon. So uh, apologies—he just really needed to talk and stuff. But I moved the thing. Uh, I'm just two years in. I've now learned today I am chatting with David after our meeting. After Salesforce, we're still doing the Salesforce stuff. Again, apologies for having to move the meeting from four yesterday. David doesn't overlook any of his calendars. We're gonna talk after this about Salesforce and the iframe for the relationship map so we can make some plans there. And yeah, yesterday was all relationship and post-man first of the day. Oh, Cam. I started Salesforce stuff on the 290 branch that—and then, not aware when using Salesforce. And if they come to our site, I was assuming no at this point in time with this scope of work. And then I'm assuming that will probably bring up maybe questions on how it works. I know because it didn't really address like onboarding, blah, blah. But I'm like, well, people aren't going to probably be onboarded. They'll probably just need a person who has kind of like a busy work ticket for the day. Did that have testing and stuff like that? For next steps, I decided to take the rail side ticket of provisioning a new user when they come in with that initial PR. I don't remember what the PR is now, but trying to get that set up. Okay, we'll talk about that in a few minutes. Let's just talk about Salesforce for a moment here. There are four pieces of the relationship map: offers for help, relationship leads, relationship deal team, and extended network that we want most of on this page. This is the relationship map. Obviously, there's stuff to still be worked on, but the ideas are getting pretty concrete at this point. It becomes a one-stop shop. Honestly, there's an argument to be made that there are left and right arrows on this. There are only a few things you'd have to do when looking at this page that we're trying to draw the most engagement with, which is acting upon relationships—bookmark, erase, next account—it's just a way for you to essentially act upon them. So really, the only things you can act upon on this page are the relationship leads and the offers for help. Let's really keep these things engaged and trust the concierge to do the process without deeper needs. Moving into Salesforce: this is just a rudimentary design. Salespeople don't necessarily want more platforms, and connectors sure as hell don't either. Ideally, we'd make this a truly native Salesforce piece because that always seems to be faster in terms of performance. Getting this all on one page in Salesforce is a win. The big piece is that we can work iteratively. When Cam and I talked yesterday about building out the relationship map, one of the things we said was we could probably get the offers for help, which are already in the database, on the page, along with the relationship leads. Obviously, there's a bunch of design stuff I want to do differently. The real question is about all the stuff around the iframe. We're going to get this out in a couple of weeks. In theory, we could just deploy this page to the rail side and have it load without having to do all the relationship deal team and extended network stuff that requires the concierge doing work. In the meantime, we could build the iframe. Not that we're saying we'd definitely build this eventually, but if we see good uptake, then yes, I think we would want to build it. The iframe can be built, and the content can be built right along with the relationship map page itself. Regarding the Chrome: when you log in, I think we'd like a custom login page. Or we do what we did for the connector dashboard, which wasn't the worst. We could rebuild the page to not have any of that Chrome. The other piece is thinking about what we want if they're not logged in, with the shared link thing and the custom modal. We could fake it where it looks like you're on the relationship page. It's a custom modal that I built that sits on top of an image of the background, so you can run through the login process without asking. That's identification, it's not authentication. Even if we could expose this, what other easier ways could there be? We could put less onus on the user. Worst case scenario, if you find a way to do it, we'd still probably have to have that for people who aren't licensed or something like that. We have to build a separate login page that fits the iframe, stuff like that, which we already have to do. That's what we're assuming we have to do. So if you want to take a full exploratory round for a few days of testing the waters—it smells and feels kind of dangerous, but could things be done to, you know, yeah. It smells and feels dangerous right now where we have headers, but that's very trusted kind of stuff. When you're a requester, you kind of only need an account to be present until you take action. But then, that was maybe about shared secrets we already have. We didn't need them. So if we can essentially ignore all origin problems, it really becomes an authorization problem. Like, does this person have the authority? The due diligence into the logic for that, I don't know. I think it's a question of the Salesforce internal admin and the whole thing from the beginning. I don't know if it's done in practice, but I can see it being done. It seems logical. Cool. So I'll also take it for you just based on this conversation to get some exploration. And then next week as we get a little closer, we'll do more. That seems like a win. Salesforce administration, that's what I would think. But I don't know. I feel like Salesforce administrators are probably an abused population. Okay. Well, they can literally say only allow these people to see these accounts because they're the owners or they're in that region or something like that. They can configure it on their own account object. So just like you can say in Salesforce, when we have them install stuff, turn this on for these users who should not be allowing people to look at other accounts. They can do that. Well, and we just got our May 1 bill. I'll take it. Let's start testing the waters a little. Let us know if that's a feasible approach. Yeah, that makes me so very happy. Cool. Okay. I will send that ticket together. April 1, yes. That's what's going to be on the page. We'll have better documentation by May 1. One last thing—the new frontend, three of us involved, but we're kind of gearing up before we go to eat. Okay, no worries. Thanks for letting us know. We can leave it there then. All right, have a good day. Thank you guys so much. ### Casual chat highlights and games **8:40 AM - 9:13 AM PDT** | *casual* **Microphone:** What? Oh god, so many highlights and I was just trying them out. I have like seven highlights you can turn into some crazy fucking LARPing-ass fucking flight. Okay. Oh man, I mean, maybe—dude, so I made one too. Listen, it's a little long, but it's not bad. Not bad? That's not awful. You want to kill me? I mean, I kind of like the idea of having value be part of it. I know it's technically in there—it's at value dot. And those were the two that I found that were unavailable, but I've followed them in the past. I know their names were, and most of them were pretty easy to spell. Things, but I think if it's any sort of Twitter brand that I interact with, it's very easy to tag. Let's get it live. That's the username? Good, works as evil. That's like the one person I followed too. And Noah. Good luck, dude. Let's see. Don't forget to do the last filter. Okay, let's see this. Should it be "value" or "val-you"? Got it. Hello, Maria. You're true. I think I'm gonna go—value, got it. Say that? God damn it. There. You haven't been smoking cigarettes, have you? No, only one I saw at the low. I don't know. Dude, what the fuck? How do you change your fucking Twitter profile after you already set your account? Fuck. I'm gonna have to create a whole new one. That'd be really gay. Here we go, barely got it. Sweet. Some shit like that, yeah? Other—Machiavelli, that works. Bye. Yeah, I should download Firecamp. I'm not sure. I'm going to go. What? That's funny. I mean, I bet people will fuck with it, dude. I had Lauren take pictures of me working for a comeback story. Yep, exactly. Thank God, because I took no pictures on the way. All right, yeah. North Coast, yeah. Or Riot Fest. I couldn't tell which one it was. I thought it was North Coast, but—I thought it was North Coast too. I think anyway it was North Coast. It was Ned Dome. Yeah, I feel so fine. Yeah, I don't know. It makes me want to go back sometimes. Bro, I was having so much fun while I was a kid. That turned you into a demon. I don't know. Oh shit, what's funny? Yeah, you were stressing me out, I remember. That'd be a picture of us? Should it be? Should we just use the fucking Machiavelli profile picture? Yeah, yeah, that seems reasonable. Let's do that. Right, the fucking vibe on original source stuff—like Google Drive or something. Yeah, no, you can just—have to go spend a couple hours. But it's just not as high quality as we need it. We just need the original photos. Whatever you can do to export from CapCut would also work too. Or it's a little bit of a mess because there's like that Snapchat shit that we need to like fucking crop out. I'm gonna blame—have access to my email? But no, but here I did at one point. Because like—okay, not gonna make it black and white though. Let's see, I'm trying to find a fucking Machiavelli picture. Oh shit, okay. What's your email? Holikowski at gmail.com. See if that link works. I was just like—I'm afterwards I was like—and did they do it? Yes. The marketing team lives like literally a block away from me. Oh, that's crazy. I know, it's a fucking bomb. Um, check out what I sent you. Oh, okay, this is a football picture. Why does it look like that? What? It's just not a face, you? I mean, I'm open to suggestions. So like, fuck, I'll change it every day if we want to, just put different quotes on. Saw yeah, yeah, absolutely, bro. Oh, you must have been a second one though, right? I should be able to. Did it first. Say project, try again? Let's open it up one more time. Damn, I don't know what's wrong. Did you put—fuck, is this thing of clicking? Couldn't save project, try again. I assume that's because. Is that something? Good. Yeah, just know we gotta pay for this shit if we wanna share it. Yeah, that's better. Okay, cool. It should be. Thank you. No, no. Let's see. Go black and white. You can't tell anybody about this yet. It's been a long time. My plan is to let the makers come across it, let them put it together. And I mean, I hear that for him. Ha ha, I don't know. Oh, that's it. Hope. Make on private probe. Mm-hmm. Yeah, I mean, I think. And I'm sure there's similar strategies and stuff. Was my credit card good? Oh shit, here we go. I'm gonna have an AI fucking do a clip video. Um, that we can't do something super similar. I've still got some research to do. I don't know what the best way to move on Twitter is. Bye. What the fuck? Both? I feel like this coffee-ass jasmine is. Um, how the fuck do I had a relationship. Fuck. Sorry. Um, here, take it to Instagram. I'll upload it to Instagram and then download it. I found it. Oh boy, that should be fun. AI Ultra HD, I will take all the videos. I'm sorry. So a lot of—let's see here. Ton. One-point-five. And that's what I'm saying. White with all of these? That sucks. I'm just worried it's gonna fucking degrade the quality. Yeah, that makes sense. It's just like whenever it has to get processed, it gets worse. Learn how to fucking navigate this shit. Oh, I don't know how. Thank, just put way about this, but uh, yeah. Yes. But is like a fake black and white. We'll just have to keep it consistent though. I'll need to save what this filters. Let's watch it through. Prog by SD Kid. Thank you. I mean, I like SD Kid. I can't find it, though. That's not good. P-R-A-G-U-E. Spell fucking product. It's just not available through CapCut. Do I need on my computer then? I mean, you just need iMovie basically. Have to drive and launch there for right now, but I'll do it when I get back. I'll give a podcast for another night. All right, you two left. Lots of deuces. Cheers. **System Audio:** Thank you.
The SmallWorld team's morning standup focused heavily on infrastructure cost optimization and autoscaling strategy for Sidekiq workers, driven by a ~$4,500 cost incident and pressure from Postman to process data faster. The team celebrated a dramatically reduced AWS bill ($800 for May 1) and now has full Sidekiq job instrumentation in DataDog for the first time. A significant architectural discussion around embedding SmallWorld's relationship map into Salesforce via iframe took shape, with the team aligning on an iterative approach — ship offers-for-help and relationship leads first, defer deal team and extended network until the concierge is ready. Authentication strategy for the iframe remains an open question requiring exploration.